애자일 소프트웨어 개발

"오늘의AI위키"는 AI 기술로 일관성 있고 체계적인 최신 지식을 제공하는 혁신 플랫폼입니다.
"오늘의AI위키"의 AI를 통해 더욱 풍부하고 폭넓은 지식 경험을 누리세요.

1. 개요
2. 역사
- 2.1. 애자일 선언문
3. 주요 특징
4. 종류
5. 적용 대상 및 한계
6. 비판
참조

1. 개요

애자일 소프트웨어 개발은 1990년대에 등장한 소프트웨어 개발 방법론으로, '무거운' 개발 방식에 대한 반작용으로 여러 경량 방법론들이 발전하면서 시작되었다. 2001년, 17명의 개발자들이 유타주 스노우버드에서 '애자일 소프트웨어 개발 선언문'을 발표하며 핵심 가치를 제시했다. 애자일 개발은 개인과 상호작용, 작동하는 소프트웨어, 고객과의 협력, 변화에 대한 대응을 중요하게 여기며, 적응형 계획과 반복적 실행을 통해 시장 출시 속도와 위험 완화를 추구한다. 주요 특징으로는 효율적인 의사소통, 대면 상호작용, 품질 중심 개발을 강조하며, 익스트림 프로그래밍(XP), 스크럼, 크리스털 패밀리 등 다양한 종류가 있다. 애자일 개발은 소규모 팀, 복잡한 문제, 빈번한 요구사항 변경 환경에 적합하지만, 대규모 팀, 지리적 분산 환경, 미션 크리티컬 시스템에는 적용이 어려울 수 있다. 비판으로는 대규모 조직에서의 비효율성, 경영 유행으로의 변질, 학습 및 구현 비용 등이 있으며, 하이브리드 방식도 채택되고 있다.

더 읽어볼만한 페이지

애자일 소프트웨어 개발 - 유스 케이스
유스 케이스는 시스템과 액터 간 상호작용을 통해 시스템 목표 달성에 기여하는 동작들을 나타내는 요구 사항 캡처, 모델링, 명세 기법으로, 객체 지향 소프트웨어 공학에서 기능 요구 사항을 캡처하는 데 중요한 역할을 하며 다양한 분야에서 활용된다.
애자일 소프트웨어 개발 - 스크럼 (애자일 개발 프로세스)
스크럼은 제품 개발을 위해 반복적, 점진적 접근 방식을 사용하는 애자일 소프트웨어 개발 방법론의 프레임워크로, 제품 책임자, 개발자, 스크럼 마스터로 구성된 팀을 중심으로 투명성, 검사, 적응의 원칙을 따른다.
소프트웨어 개발 철학 - 유닉스 철학
유닉스 철학은 단순성, 모듈성, 재사용성을 중시하며, 한 가지 일을 잘하는 프로그램, 협력적인 프로그램, 텍스트 스트림 처리 프로그램을 지향하는 소프트웨어 설계 원칙으로, 현대 운영체제 및 소프트웨어 설계에 영향을 주지만 비판도 존재한다.
소프트웨어 개발 철학 - 폭포수 모델
폭포수 모델은 소프트웨어 개발 방법론 중 하나로, 요구사항 분석부터 운영 및 유지보수까지 순차적으로 단계를 진행하며, 각 단계가 완료되어야 다음 단계로 넘어가는 방식을 따른다.
소프트웨어 프로젝트 관리 - 소프트웨어 개발
소프트웨어 개발은 요구사항 분석, 설계, 코딩, 테스트, 배포, 유지보수를 포함하는 컴퓨터 프로그램 및 관련 데이터를 만드는 과정으로, 다양한 방법론과 도구가 사용되며, 개발자 외에도 다양한 전문가들이 참여한다.
소프트웨어 프로젝트 관리 - 브룩스의 법칙
브룩스의 법칙은 소프트웨어 개발 프로젝트 후반에 인력을 추가하면 프로젝트가 지연된다는 법칙으로, 지연된 프로젝트에 인력을 추가하는 것이 단기적으로 팀 생산성을 저하시키고 커뮤니케이션 비용을 증가시키기 때문에 발생한다.

애자일 소프트웨어 개발
개요
애자일 소프트웨어 개발
설명	애자일 방법론은 소프트웨어 개발에 대한 반복적인 접근 방식을 사용하는 개념적 프레임워크임. 소프트웨어 개발에 대한 특정한 접근 방식의 집합을 지칭하는 포괄적인 용어임.
특징	지속적인 계획 지속적인 테스트 지속적인 통합 기타 지속적인 소프트웨어 개발 수명 주기 단계
핵심 가치
개인과 상호작용	프로세스와 도구보다 중요함
작동하는 소프트웨어	포괄적인 문서보다 중요함
고객과의 협력	계약 협상보다 중요함
변화에 대한 대응	계획을 따르는 것보다 중요함
애자일 방법론의 종류
종류	스크럼 익스트림 프로그래밍 사용자 기능 중심 개발 린 소프트웨어 개발 동적 시스템 개발 방법 크리스탈 클리어 적응형 소프트웨어 개발
관련 개념
관련 개념	DevOps 지속적 통합 테스트 주도 개발
역사
애자일 선언	2001년

2. 역사

애자일 소프트웨어 개발은 반복적이고 점진적인 개발 방식의 연장선상에 있으며, 그 기원은 1957년까지 거슬러 올라간다.^[8] 1970년대에는 적응형 소프트웨어 개발^[11] 등이 등장했다.^[12]

1990년대에는 당시 지배적이었던 '무거운' 방법론(주로 폭포수 모델)에 대한 반작용으로 여러 "경량" 소프트웨어 개발 방법들이 발전했다.^[13] 이러한 경량 방법론에는 신속한 애플리케이션 개발(RAD)(1991년),^[14]^[15] 통합 프로세스(UP)와 동적 시스템 개발 방법(DSDM)(1994년), 스크럼(1995년), 익스트림 프로그래밍(XP)(1996년), 기능 중심 개발(FDD)(1997년) 등이 포함된다.^[16]

2001년, 유타주 스노우버드에서 17명의 소프트웨어 개발자들이 모여 경량 개발 방법에 대해 논의하고, 애자일 소프트웨어 개발 선언을 발표하면서 애자일 방법론은 하나의 통합된 철학으로 자리 잡았다.^[2]

이후 2005년에는 프로젝트 관리 원칙에 대한 부록인 상호 의존성 선언,^[20] 2009년에는 소프트웨어 장인정신 선언문이^[21] 작성되는 등 애자일 개발은 지속적으로 발전해왔다.

2. 1. 애자일 선언문

우리는 소프트웨어를 개발하고, 또 다른 사람의 개발을 도와주면서 소프트웨어 개발의 더 나은 방법들을 찾아가고 있다. 이 작업을 통해 우리는 다음을 가치있게 여기게 되었다.

공정과 도구보다 '''개인과 상호작용'''을
포괄적인 문서보다 '''작동하는 소프트웨어'''를
계약 협상보다 '''고객과의 협력'''을
계획을 따르기보다 '''변화에 대응하기'''를

가치있게 여긴다. 이 말은, 왼쪽에 있는 것들도 가치가 있지만, 우리는 오른쪽에 있는 것들에 더 높은 가치를 둔다는 것이다.^[24]

스콧 암블러는 다음과 같이 설명했다.

도구와 프로세스는 중요하지만, 유능한 사람들이 효과적으로 함께 일하는 것이 더 중요하다.
훌륭한 문서는 사람들이 소프트웨어가 어떻게 구축되었고 어떻게 사용하는지 이해하는 데 유용하지만, 개발의 요점은 문서가 아니라 소프트웨어를 만드는 것이다.
계약은 중요하지만, 고객과 긴밀히 협력하여 그들이 무엇을 필요로 하는지 파악하는 것을 대체할 수 없다.
프로젝트 계획은 중요하지만, 기술이나 환경의 변화, 이해 관계자의 우선 순위, 문제와 그 해결책에 대한 사람들의 이해를 수용할 수 있도록 너무 경직되어서는 안 된다.

짐 하이스미스는 애자일 연합을 대표하여 선언문을 소개하며 다음과 같이 말했다.

2001년, 미국 유타주의 스노우버드라는 스키 리조트에 모여, 경량 소프트웨어 개발 방법론 분야에서 명성이 있는 17명^[124]이 각각 별도로 제창하던 개발 방법론이 공유하는 가치관을 논의했다. 그들은 그 결과를 "[http://agilemanifesto.org/iso/ko/manifesto.html 애자일 소프트웨어 개발 선언]"(''Manifesto for Agile Software Development'')이라는 문서로 정리했다.

이 선언은 다음과 같은 4가지 가치관을 제시한다.

'''개인과 상호 작용'''을 프로세스와 도구보다 더 가치 있게 생각한다.
'''작동하는 소프트웨어'''를 포괄적인 문서보다 더 가치 있게 생각한다.
'''고객 협업'''을 계약 협상보다 더 가치 있게 생각한다.
'''변화에 대한 대응'''을 계획 준수보다 더 가치 있게 생각한다.

3. 주요 특징

애자일 방법론은 기존의 개발 방식과 비교하여 다음과 같은 주요 특징을 갖는다.

애자일 방법론은 문서 중심의 개발 방식이 아니라, 실제 코딩을 통한 개발 방식(code-oriented)을 택한다. 폭포수 모델이나 나선 모형과 같은 고전적인 방법론과 달리, 애자일 방법론은 예측하며 개발을 하지 않고, 일정한 주기를 가지고 프로토타입을 지속적으로 만들어내며 요구사항을 더하고 수정하여 소프트웨어를 개발한다.

애자일 개발 프로세스는 "애자일(Agile=기민한, 좋은 것을 빠르고 낭비 없게 만드는 것)" 개발을 가능하게 해 주는 다양한 방법론 전체를 일컫는 말이다. 익스트림 프로그래밍(XP)이 대표적인 애자일 개발 프로세스 방법이다.

90년대 후반까지의 소프트웨어 개발 방법론은 다른 공학의 프로세스와 비슷하게 장기간에 걸쳐 많은 인력과 비용을 투입하여 진행되었다. 그러나 소프트웨어는 유동적이고 개방적이며 요구사항 변경에 따른 작업량을 예측하기 어렵다. 객체 지향 기술은 이러한 문제에 대한 기술적인 해결책으로, 애자일 개발 프로세스는 객체 지향 기술을 기반으로 하는 경우가 많다.

전통적인 개발 프로세스들은 폭포수 모델과 계획 기반 개발을 따르는 반면, 애자일 개발 프로세스는 경험적 프로세스 제어 모델로 개발을 관리한다. 경험적 프로세스 제어 모델은 불확실성을 수반하고 포용한다.

애자일 프로젝트 관리는 반복적인 개발 프로세스로, 사용자 및 이해 관계자로부터 지속적으로 피드백을 수집하여 적절한 사용자 경험을 창출한다. 애자일 프로세스를 수행하기 위해 스크럼, 익스트림 프로그래밍, 린, 칸반 등 다양한 방법을 사용할 수 있다.^[102] 애자일 관리는 비즈니스 및 정부 부문에도 적용되고 있다. 예를 들어, 미국 연방 정부 내 미국 국제 개발처(USAID)는 협력, 학습 및 적응(CLA) 전략을 통합하여 프로그래밍을 반복하고 적용하는 데 중점을 둔 협업 프로젝트 관리 접근 방식을 사용하고 있다.^[108]

애자일 소프트웨어 개발 방법론은 소프트웨어 제품 개발뿐만 아니라 컴퓨터, 의료 기기, 식품, 의류, 음악 등 비 소프트웨어 제품 개발에도 적용될 수 있다.^[112] IT 인프라 구축 및 마이그레이션에도 사용되어 왔으며, 비즈니스 애자일 또는 애자일 비즈니스 관리라는 용어 아래 일반 관리에도 적용되었다.^[113]

3. 1. 적응성 vs 예측성

애자일 소프트웨어 개발 방법론은 변화에 빠르게 적응하는 것을 목표로 한다. 이는 예측을 중심으로 개발을 진행하는 전통적인 방법론과 대조된다.

'''적응형 방법론'''은 변화하는 상황에 맞춰 빠르게 대응한다. 프로젝트 요구사항이 바뀌면, 팀도 함께 변화한다. 적응형 팀은 미래를 정확히 예측하기 어렵다. 시간이 지날수록 해야 할 일에 대한 구체적인 내용은 불분명해진다. 다음 주에 무엇을 할지는 정확히 말할 수 있지만, 다음 달에는 어떤 기능을 만들지에 대해서만 이야기할 수 있다. 6개월 후의 출시 계획은 미션 선언문이나 예상되는 가치와 비용 정도만 설명할 수 있다.

'''예측형 방법론'''은 미래를 자세히 분석하고 계획하여 알려진 위험에 대비한다. 극단적인 경우, 예측형 팀은 개발 과정 전체에서 어떤 기능과 작업을 할지 정확하게 보고할 수 있다. 하지만 초기 분석이 잘못되면 프로젝트 방향을 바꾸기 어려울 수 있다. 그래서 예측형 팀은 보통 변경 관리 위원회를 두어 중요한 변경 사항만 고려한다.

배리 뵘과 리처드 터너는 어떤 개발 방법론을 선택할지 위험 분석을 통해 결정할 수 있다고 제안했다. 각 방법론은 다음과 같은 특징을 가진다.^[55]

서로 다른 개발 방법론의 특징
가치 중심 방법론 (애자일)	계획 중심 방법론 (폭포수)	형식적 방법론
중요도가 낮음	중요도가 높음	중요도가 매우 높음
경험이 많은 개발자	경험이 적은 개발자(?)	경험이 많은 개발자
요구 사항이 자주 바뀜	요구 사항이 자주 바뀌지 않음	제한된 요구 사항, 제한된 기능, 비르트의 법칙 참조
개발자 수가 적음	개발자 수가 많음	모델링 가능한 요구 사항
변화에 대응하는 문화	질서를 중요시하는 문화	매우 높은 품질

애자일 개발 프로세스는 제한된 시간과 비용 안에서 정보가 불완전하고 예측이 불가능하다는 전제를 가진다. 그리고 그 전제 아래에서 합리적인 답을 내도록 한다. 전통적인 개발 프로세스들은 폭포수 모델과 계획 기반 개발을 따르는 반면, 애자일 개발 프로세스는 그에 반한다는 점에서 가장 큰 차이를 가진다.

반복적이고 점증적인 소프트웨어 개발 방법은 1957년으로 거슬러 올라갈 수 있으며,^[8] 진화적 프로젝트 관리^[9]^[10]와 적응형 소프트웨어 개발^[11]은 1970년대 초에 등장했다.^[12]

'''적응형''' 가치 제공에서는 완벽한 예측이 어렵다는 것을 인정하고, 실제 가치 제공을 통해 배우는 것을 중시한다. 가설로서 문제를 정하고, 해결책을 만들고, 그것을 실제 사용자에게 제공한다. 이 실제 가치 제공을 통해 가설에 대한 학습을 얻는다(예: 아예 사용되지 않음, 사용되지만 매우 사용하기 어려움). 이 학습을 바탕으로 가치 제공을 적응시킨다. 즉 문제 자체와 그 해결책을 방향 수정한다. 설령 사전에 완벽한 예측이 불가능하더라도, 빠르게 적응하고 가치를 높여감으로써 단계적으로 좋은 가치 제공이 가능해진다.

계획 유형은 '''예측형'''과 '''적응형'''으로 분류된다. 예측형은 "사전의 충분한 예측으로 완성형 계획을 수립할 수 있다"는 입장을 취하며, 필요한 계획을 사전에 확정한다. 반면 적응형은 "초기 계획을 실행하고, 실행 결과에 따라 계획을 적응시킨다"는 입장을 취하며, 작은 계획·가설을 세워 실행하고 파악된 문제점을 통해 계획 자체를 개선한다.

애자일은 가치의 실증과 적응을 반복하기 때문에, 적응형 계획·반복형 실행 유형의 개발이다.^[141] 반복적 개발도 같은 유형으로 분류된다. 사전에 완벽한 계획을 세우고 다음에 구현·테스트를 진행하는, 즉 예측형 계획·순차형 실행의 개발 스타일의 대표적인 예는 폭포수 모델이다.^[142] 애자일과 워터폴은 개발 프로세스가 완전히 다르다.

개발 패턴의 분류
colspan="2" rowspan="2" \|	계획
예측형	적응형
실행	순차형	워터폴
실행	반복형	단계 릴리스	애자일・반복적 개발

개발 유형에 따라 완성 시기나 안고 있는 리스크가 다르다. 애자일은 다른 유형과 비교하여, 완성 시기의 전망이 초기에 서지 않는다는 리스크가 있다. 이는 계획 자체가 점차 개선되어 비로소 의미 있는 계획이 되는 특성에 기인하므로, 본질적으로 피할 수 없는 리스크이다.

개발 유형과 특성
유형	완성 시기	품질	리스크
예측형 계획・순차형 실행	프로젝트 종료 시	일정(계획의 질에 따라 다름)	불완전한 계획으로 인한 전체적인 재작업・품질 부족
예측형 계획・반복형 실행	기능별 단계 릴리스	일정(계획의 질에 따라 다름)	불완전한 계획으로 인한 기능 수준의 재작업・품질 부족
적응형 계획・반복형 실행	기능별 단계 릴리스	낮음→중간→높음	초기 단계에서는 완성 시기가 불명확함

3. 2. 반복적, 점진적, 진화적 개발

애자일 방법론은 짧은 주기의 반복(Iteration)을 통해 개발을 진행한다. 각 반복마다 계획, 분석, 설계, 코딩, 단위 테스트 및 인수 테스트 등 모든 개발 단계를 거쳐 작동하는 소프트웨어를 제공한다.^[25] 이러한 반복적인 개발 방식을 통해 위험을 최소화하고, 변경 사항에 신속하게 대응하며, 고객에게 지속적으로 가치를 제공한다.

반복은 시장 출시를 보장할 만큼 충분한 기능을 추가하지 못할 수 있지만, 목표는 각 반복이 끝날 때마다 (최소한의 버그) 사용 가능한 릴리스를 갖는 것이다.^[26] 증분 개발을 통해 제품은 최종 출시일에 갑작스럽게 실패하는 대신 각 반복 단계에서 "자주 그리고 일찍 실패"할 여지가 있다.^[27]

애자일 방식의 주요 장점은 시장 출시 속도와 위험 완화이다. 더 작은 단위로 시장에 출시되어 사용자 요구 사항을 충족하지 못하는 제품을 엔지니어링하는 데 드는 시간과 비용 위험을 줄인다.

애자일 소프트웨어 개발 방법과 폭포수 모델의 차이점 중 하나는 품질과 테스팅에 대한 접근 방식이다. 폭포수 모델에서는 '''''테스팅 단계'''''는 별도로 존재하며 '''''빌드 단계''''' 다음에 진행된다. 하지만 애자일 소프트웨어 개발에서는 테스팅이 프로그래밍과 동일한 반복 작업 내에서 완료된다.

테스팅은 소프트웨어의 작은 부분을 개발하는 각 반복 작업에서 수행되기 때문에, 사용자는 새롭게 개발된 소프트웨어 조각을 자주 사용하고 그 가치를 검증할 수 있다. 사용자는 업데이트된 소프트웨어 조각의 실제 가치를 알게 된 후, 소프트웨어의 미래에 대해 더 나은 결정을 내릴 수 있다. 각 반복 작업(스크럼은 일반적으로 2주 간격으로 반복 작업을 수행한다)에서 가치 회고 및 소프트웨어 재계획 세션을 갖는 것은 팀이 제공하는 가치를 극대화하기 위해 계획을 지속적으로 조정하는 데 도움이 된다. 이는 계획-실행-점검-조치 (PDCA) 사이클과 유사한 패턴을 따른다.

이 반복적인 접근 방식은 '프로젝트'가 아닌 '제품' 마인드를 지원한다. 이는 개발 과정 전반에 걸쳐 더 큰 유연성을 제공한다. 반복적인 제품 개발을 통해 소프트웨어는 비즈니스 환경 또는 시장 요구 사항의 변화에 대응하여 발전할 수 있다.

애자일은 가치의 실증과 적응을 반복하기 때문에, 적응형 계획·반복형 실행 유형의 개발이다.^[141] 반복적 개발도 같은 유형으로 분류된다.

개발 패턴의 분류
colspan="2" rowspan="2" \|	계획
예측형	적응형
실행	순차형	폭포수 모델	(해당 없음)^[143]
실행	반복형	단계 릴리스	애자일・반복적 개발

개발 유형에 따라 완성 시기나 안고 있는 리스크가 다르다. 애자일은 다른 유형과 비교하여, 완성 시기의 전망이 초기에 서지 않는다는 리스크가 있다.

개발 유형과 특성
유형	완성 시기	품질	리스크
예측형 계획・순차형 실행	프로젝트 종료 시	일정(계획의 질에 따라 다름)	불완전한 계획으로 인한 전체적인 재작업・품질 부족
예측형 계획・반복형 실행	기능별 단계 릴리스	일정(계획의 질에 따라 다름)	불완전한 계획으로 인한 기능 수준의 재작업・품질 부족
적응형 계획・반복형 실행	기능별 단계 릴리스	낮음→중간→높음	초기 단계에서는 완성 시기가 불명확함

3. 3. 효율적인 의사소통과 대면 상호작용

애자일 소프트웨어 개발의 여섯 번째 원칙은 "개발 팀과의 정보 전달 및 팀 내 정보 전달에 가장 효율적이고 효과적인 방법은 대면 대화이다"라고 명시하고 있다.^[28] 이는 정보를 전달할 때 대면 상호작용을 통해 질문과 답변이 오가며, 전화, 채팅, 위키 또는 이메일 등을 통해 정보를 전달할 때 일반적으로 소요되는 시간을 줄여준다.^[29]

같은 팀원들이 함께 위치하여 팀으로서의 정체성을 확립하고 의사소통을 개선하는 것을 동일 장소 원칙이라고 한다.^[28] 그러나 COVID-19 팬데믹 기간 동안 원격 근무가 널리 채택되면서 동일 장소 근무가 점점 덜 중요해지고 있다는 연구 결과도 있다.^[30]

어떤 개발 방식을 따르든 모든 팀에는 고객 대표(스크럼에서는 '제품 책임자'라고 함)가 포함되어야 한다. 고객 대표는 이해 관계자들을 대신하여 행동하고, 개발자들이 질문에 답변할 수 있도록 돕는다.

애자일 소프트웨어 개발에서 '''정보 방사기'''는 개발 팀 근처의 눈에 잘 띄는 곳에 위치한 큰 물리적 디스플레이나 스티커 메모 등을 말하며, 지나가는 사람들이 프로젝트의 진행 상태를 확인할 수 있게 한다.^[32] 빌드 라이트 표시기 역시 제품 개발의 현재 상태를 알리는 데 사용될 수 있다.

애자일 소프트웨어 개발의 일반적인 특징 중 하나는 데일리 스탠드업(스크럼 프레임워크에서는 '데일리 스크럼'이라고 함)이다. 이는 짧은 시간(예: 15분) 동안 진행되는 회의로, 팀원들은 목표를 향해 어떻게 진행하고 있는지 검토하고, 접근 방식을 조정해야 하는지 논의한다. 일반적으로 전날 완료한 작업, 해당 일에 완료할 목표, 진행에 방해되는 요소나 위험이 있는지 등에 대해 이야기하며, 자세한 논의와 문제 해결은 스탠드업 미팅 이후에 이루어진다.^[90]

3. 4. 품질 중심

지속적인 통합, 자동화된 단위 테스트, 페어 프로그래밍, 테스트 주도 개발, 디자인 패턴, 행위 주도 개발, 도메인 주도 설계, 코드 리팩토링과 같은 구체적인 도구와 기법은 품질을 향상시키고 제품 개발 민첩성을 높이기 위해 자주 사용된다.^[34] 이는 처음부터 품질을 설계하고 구축하여 고객에게 언제든지, 적어도 각 반복의 끝에서 소프트웨어를 시연할 수 있다는 전제에 기반한다.^[35]

애자일 소프트웨어 개발 방법과 폭포수 모델의 차이점 중 하나는 품질과 테스팅에 대한 접근 방식이다. 폭포수 모델에서는 작업이 소프트웨어 개발 생명 주기 (SDLC) 단계를 거쳐 진행되며, 한 단계가 완료된 후에야 다음 단계가 시작된다. 따라서 '''''테스팅 단계'''''는 별도로 존재하며 '''''빌드 단계''''' 다음에 진행된다. 하지만 애자일 소프트웨어 개발에서는 테스팅이 프로그래밍과 동일한 반복 작업 내에서 완료된다.

테스팅은 소프트웨어의 작은 부분을 개발하는 각 반복 작업에서 수행되기 때문에, 사용자는 새롭게 개발된 소프트웨어 조각을 자주 사용하고 그 가치를 검증할 수 있다. 사용자는 업데이트된 소프트웨어 조각의 실제 가치를 알게 된 후, 소프트웨어의 미래에 대해 더 나은 결정을 내릴 수 있다. 각 반복 작업(스크럼은 일반적으로 2주 간격으로 반복 작업을 수행한다)에서 가치 회고 및 소프트웨어 재계획 세션을 갖는 것은 팀이 제공하는 가치를 극대화하기 위해 계획을 지속적으로 조정하는 데 도움이 된다. 이는 계획-실행-점검-조치 (PDCA) 사이클과 유사한 패턴을 따르며, 작업은 ''계획''되고, ''실행''되며, (검토 및 회고에서) ''점검''되고, 합의된 변경 사항은 이에 따라 ''조치''된다.

애자일 개발의 반복적인 특성 때문에 여러 차례의 테스트가 필요하다. 자동화된 테스트는 반복적인 단위 테스트, 통합 테스트, 회귀 테스트의 영향을 줄이는 데 도움이 되며, 개발자와 테스터가 더 가치 있는 작업에 집중할 수 있도록 한다.^[94]

테스트 자동화는 또한 반복적인 소프트웨어 개발에 필요한 지속적인 리팩토링을 지원한다. 개발자가 리팩토링이 애플리케이션의 기능을 수정하지 않았는지 신속하게 테스트를 실행하여 확인할 수 있도록 함으로써 작업량을 줄이고, 정리 작업으로 새로운 결함이 발생하지 않았다는 확신을 높일 수 있다.

4. 종류

애자일 방법론에는 다양한 종류가 있으며, 각 방법론은 특정 상황과 목적에 맞게 선택하거나 조합하여 사용할 수 있다. 주요 애자일 개발 프레임워크는 다음과 같다.^[46]

프레임워크	주요 기여자
적응형 소프트웨어 개발 (ASD)	짐 하이스미스, 샘 바이어
애자일 모델링	스콧 앰블러, 로버트 C. 마틴
애자일 통합 프로세스(AUP)	스콧 앰블러
규율 기반 애자일 제공	스콧 앰블러
동적 시스템 개발 방법 (DSDM)	제니퍼 스테이플턴
익스트림 프로그래밍 (XP)	켄트 백, 로버트 C. 마틴
기능 중심 개발 (FDD)	제프 드 루카
린 소프트웨어 개발	메리 포펜딕, 톰 포펜딕
린 스타트업	에릭 리스
칸반	오노 타이이치
신속한 애플리케이션 개발 (RAD)	제임스 마틴
스크럼	켄 슈와버, 제프 서덜랜드
스크럼반

애자일 소프트웨어 개발은 요구 사항, 설계, 모델링, 코딩, 테스트, 계획, 위험 관리, 프로세스, 품질 등 다양한 영역을 포괄하는 구체적인 실천 방법으로 뒷받침된다. 주요 애자일 소프트웨어 개발 실천 방법은 다음과 같다.^[46]

실천 방법	주요 기여자
인수 테스트 기반 개발 (ATDD)	켄 퍼
애자일 모델링	스콧 앰블러
애자일 테스팅	리사 크리스핀, 자넷 그레고리
백로그 (제품 및 스프린트)	켄 슈와버, 제프 서덜랜드
행위 주도 개발 (BDD)	댄 노스, 리즈 키오
지속적 통합 (CI)	그레이디 부치
교차 기능 팀
데일리 스탠드업 / 데일리 스크럼	짐 코플린
도메인 주도 설계 (DDD)	에릭 에반스
반복적 및 점진적 개발 (IID)
페어 프로그래밍	켄트 백
플래닝 포커	제임스 그린닝, 마이크 콘
리팩토링	마틴 파울러
회고	에스더 더비, 다이애나 라슨, 벤 린더스, 루이스 곤칼베스
스크럼 이벤트 (스프린트 계획, 스프린트 검토 및 회고)	켄 슈와버, 제프 서덜랜드
예제 기반 명세
스토리 주도 모델링	알버트 쥉도르프
테스트 주도 개발 (TDD)	켄트 백
타임박싱
사용자 스토리	앨리스테어 코크번
속도 추적

이 외에도 다음과 같은 애자일 개발 방법론 및 기법들이 존재한다.

다이내믹 시스템 개발 방법론 (DSDM)^[151]
규율 기반 애자일 제공
익스트림 프로그래밍 (XP)^[152]
사용자 기능 주도 개발 (FDD)^[153]

칸반 (소프트웨어 개발)
RAD(신속 응용 프로그램 개발)
스크럼^[155]
스크럼반
Crystal Clear 및 기타 Crystal 개발 기법^[156]

기타 기법으로는 Agile Documentation,^[157] Agile ICONIX, Microsoft Solutions Framework (MSF), Agile Data Method,^[158] Database refactoring^[159] 등이 있다. 린 생산 방식 (Lean manufacturing)은 소프트웨어 개발과 직접적인 관계는 없지만 유사한 기법으로 볼 수 있다.

5. 적용 대상 및 한계

애자일 소프트웨어 개발 방법론은 목표 달성을 위한 프로세스가 없거나, 전통적인 프로세스가 제대로 작동하지 않는 조직에 유용하다. 애자일 방법론은 소규모 팀, 빈번한 요구사항 변경이 예상되는 프로젝트, 불확실성이 높은 환경에 적합하다.

배리 뵘과 리처드 터너는 각 방법론이 다음과 같이 고유한 ''홈 그라운드''를 가지고 있다고 제안한다.^[55]

서로 다른 개발 방법론의 홈 그라운드
가치 중심 방법론 (애자일)	계획 중심 방법론 (폭포수)	형식적 방법론
낮은 중요도	높은 중요도	극단적 중요도
선임 개발자	주니어 개발자	선임 개발자
요구 사항이 자주 변경됨	요구 사항이 자주 변경되지 않음	제한된 요구 사항, 제한된 기능, 비르트의 법칙 참조
소수의 개발자	다수의 개발자	모델링할 수 있는 요구 사항
변화에 대응하는 문화	질서를 요구하는 문화	극단적인 품질

애자일 소프트웨어 개발은 그린필드 프로젝트에서 작업하는 소규모 전문가 팀과 같은 특정 유형의 환경에 매우 적합하다고 널리 알려져 있다.^[55]^[56]

그러나 대규모 팀, 분산된 환경, 미션 크리티컬 시스템, 인재 부족, 명령형 조직 문화 등에서는 애자일 방법론의 적용이 어려울 수 있다는 한계점 또한 존재한다.^[57]

20명 이상의 대규모 팀: 대규모 개발 노력에는 애자일 방법론 적용에 어려움이 있을 수 있다.^[61]^[58]
분산된(비공동 위치) 개발 팀: 여러 사업장에 팀이 분산되어 있는 경우 애자일 방법론 적용에 어려움이 있을 수 있다.^[59]^[60]
미션 크리티컬·인명과 관련된 시스템: (비)적응을 위한 "실패"가 용납되지 않는 환경에서는 애자일 방법론의 적용이 어려울 수 있다. (예: 실패를 반드시 fallback하는 설계를 통한 대응)
인재 부족: 애자일 소프트웨어 개발은 우수한 팀을 전제로 한다.
명령형 조직 문화: 애자일 소프트웨어 개발은 가치를 창출하는 자기 조직적 팀을 사용하는 사상이며, 권한 위임을 전제로 하기 때문에 명령형 조직 문화에서는 적용이 어렵다.

애자일 소프트웨어 개발 방법론은 초기에는 중요하지 않은 제품 개발에 가장 적합한 것으로 여겨졌으나, 최근에는 의료 기기, 제약, 금융, 원자력 시스템, 자동차 및 항공 전자 분야 등과 같은 규제 대상 도메인에서도 적용하려는 노력이 이루어지고 있다.^[63]^[64]^[65]^[66]^[67]

6. 비판

애자일 방식은 대규모 조직과 특정 유형의 개발에서 잠재적으로 비효율적이라고 언급되어 왔다.^[116] 많은 조직은 애자일 소프트웨어 개발 방법론이 지나치게 극단적이라고 생각하여 애자일 소프트웨어 개발과 계획 주도 접근 방식의 요소를 혼합한 하이브리드 방식을 채택한다.^[117]^[118] 동적 시스템 개발 방법론(DSDM)과 같은 일부 방법론은 기본 원칙을 희생하지 않으면서 이러한 방식을 규율 있게 시도한다.

애자일 방식의 채택이 증가함에 따라, 이는 기존의 우수한 방식을 새로운 전문 용어로 설명하고, 개발 전략에 대한 ''만능'' 사고방식을 조장하며, 결과보다 방법을 잘못 강조하는 경영 유행이라는 비판도 제기되었다.^[119]

앨리스테어 코번은 2011년 2월 12일 유타주 스노우버드에서 "애자일 소프트웨어 개발 선언문" 10주년 기념 행사를 열어, 원래 회의에 참여했던 30명 이상의 사람들을 모았다. 애자일 소프트웨어 개발 방식의 동맹, 실패 및 한계, 그리고 맥락(가능한 원인: 상업적 이익, 탈맥락화, 실패를 바탕으로 진전을 이룰 수 있는 명확한 방법 부재, 제한된 객관적 증거, 인지 편향 및 추론 오류) 정치 및 문화 등 약 20개의 숨겨진 문제('논의할 수 없는' 애자일 주제/문제) 목록이 수집되었다.^[120] 필립 크루첸은 다음과 같이 썼다.

"선언문"은 고등 교육 관리 및 리더십에 부정적인 영향을 미쳤을 수 있으며, 관리자들에게 느리고 전통적인 심의 절차를 보다 "민첩한" 절차로 대체해야 한다고 제안했다. 이 개념은 대학교수들 사이에서 거의 받아들여지지 않았다.^[121]

또 다른 비판은 애자일 관리와 전통적인 관리 방식이 여러 면에서 서로 대립하게 된다는 것이다. 이러한 방식에 대한 흔한 비판은 잠재적인 이점에도 불구하고, 방식을 배우고 구현하는 데 소요되는 시간이 너무 비싸다는 것이다. 전통적인 관리에서 애자일 관리로의 전환은 애자일에 대한 전적인 복종과 조직의 모든 구성원이 프로세스를 끝까지 지켜보겠다는 확고한 약속을 필요로 한다. 조직 전체에서 나타나는 불균등한 결과, 직원이 감당할 수 있는 수준 이상의 과도한 변화, 또는 변환 완료에 대한 보장의 부재 등은 몇 가지 예에 불과하다.^[122]

참조

_[1] 웹사이트 What is Agile? https://www.agileall[...] 2024-07-16
_[2] 웹사이트 Manifesto for Agile Software Development http://agilemanifest[...] Agile Alliance 2010-06-14
_[3] 웹사이트 Agile With a Capital "A" Vs. agile With a Lowercase "a" https://www.rallydev[...] Rally 2015-09-09
_[4] 웹사이트 What is Agile Software Development? http://www.agilealli[...] Agile Alliance 2015-04-04
_[5] 논문 Empirical studies of agile software development: A systematic review 2008-08-01
_[6] 논문 Toward Agile: An Integrated Analysis of Quantitative and Qualitative Field Data on Software Development Agility 2010-01-01
_[7] 논문 Empirical evidence in follow the Sun software development: A systematic mapping study 2018-01-01
_[8] 문서 We were doing incremental development as early as 1957 in Los Angeles, under the direction of Bernie Dimsdale at IBM's Service Bureau Corporation.
_[9] 웹사이트 Evolutionary Project Management (Original page, external archive) https://www.gilb.com[...] Gilb 2017-04-30
_[10] 웹사이트 Evolutionary Project Management (New page) http://concepts.gilb[...] Gilb 2017-04-30
_[11] 논문 A Process for the Development of Software for Nontechnical Users as an Adaptive System
_[12] 논문 Evolutionary development 1981-04-01
_[13] 백과사전 Heavyweight project organization https://doi.org/10.1[...] Springer US 2022-06-22
_[14] 서적 Rapid Application Development https://archive.org/[...] Macmillan
_[15] 서적 Inside RAD: How to Build a Fully Functional System in 90 Days or Less McGraw-Hill
_[16] 서적 Agile and Iterative Development: A Manager's Guide Addison-Wesley
_[17] 간행물 21st Century Manufacturing Enterprise Strategy: An Industry Led View Iacocca Institute, Lehigh University
_[18] 간행물 Agile Aerospace Manufacturing
_[19] 논문 A Review of Agile Manufacturing Systems https://www.research[...] 2010-11-01
_[20] 웹사이트 Declaration of Interdependence http://pmdoi.org 2018-10-04
_[21] 뉴스 How You Can Help Agile Alliance Help You 2017-07-04
_[22] 웹사이트 Examining the Agile Manifesto http://www.ambysoft.[...] Ambysoft Inc. 2011-04-06
_[23] 웹사이트 History: The Agile Manifesto http://agilemanifest[...] agilemanifesto.org
_[24] 웹사이트 Principles behind the Agile Manifesto http://www.agilemani[...] Agile Alliance 2010-06-06
_[25] 서적 Agile Risk Management Springer Verlag
_[26] 논문 Embracing Change with Extreme Programming
_[27] 논문 Agile innovation management in government: A research agenda https://linkinghub.e[...] 2016-07-01
_[28] 웹사이트 Study: Co-Located Teams vs. the Cubicle Farm https://www.infoq.co[...] 2018-10-23
_[29] 웹사이트 Agile Software Development: The Cooperative Game https://www.pearson.[...] Addison-Wesley Professional 2018-10-23
_[30] 웹사이트 Management Transformed | Research https://www.managers[...]
_[31] 논문 The Impact of Agile Software Development Process on the Quality of Software Product IEEE 2018-08-01
_[32] 서적 Agile Modeling: Effective Practices for EXtreme Programming and the Unified Process John Wiley & Sons 2002-04-12
_[33] 웹사이트 Developing agile project task and team management practices http://www.eylean.co[...] Eylean 2014-01-01
_[34] 서적 Extreme Programming installed https://archive.org/[...] Addison-Weslsy
_[35] 서적 Agile Testing: A Practical Guide for Testers and Agile Teams Addison-Wesley
_[36] 서적 Agile Development in Practice Tamare House
_[37] 서적 Agile and Iterative Development: A Manager's Guide Addison-Wesley
_[38] 서적 Balancing Agility and Discipline: A Guide for the Perplexed Addison-Wesley
_[39] 서적 Agile and Iterative Development: A Manager's Guide Addison-Wesley Professional 2013-10-14
_[40] 서적 The Software Project Manager's Bridge to Agility Addison-Wesley
_[41] 학술지 Manifesto Elicits Cynicism: Reader's letter to the editor by Steven R. Rakitin
_[42] 웹사이트 Agile/Lean Documentation: Strategies for Agile Software Development http://www.agilemode[...] 2023-04-16
_[43] 웹사이트 Just Barely Good Enough Models and Documents: An Agile Best Practice http://www.agilemode[...] 2014-01-24
_[44] 웹사이트 Do Agile Methods Require Documentation? http://www.infoq.com[...] InfoQ 2007-07-18
_[45] 기술보고서 Agile software development methods: Review and analysis http://www.vtt.fi/in[...]
_[46] 웹사이트 Guide to Agile Practices http://guide.agileal[...] the Agile Alliance
_[47] 학술지 An Agile Information Systems Development Method in use
_[48] 서적 The Paradox of Agile Transformation: Why trying too hard to be Agile stops organisations from becoming truly agile University of Auckland
_[49] 학술논문 New Directions on Agile Methods: A Comparative Analysis
_[50] 학술논문 RDP technique: a practice to customize xp ACM
_[51] 문서 Scrum is hard and disruptive.
_[52] 발표자료 The Story of LeSS. Closing Keynote. 2016-04
_[53] 학술논문 Understanding the Rarity of ISD Method Selection – Bounded Rationality and Functional Stupidity https://aisel.aisnet[...]
_[54] 학술논문 Scrum Powered by Essence
_[55] 서적 Balancing Agility and Discipline: A Guide for the Perplexed Addison-Wesley
_[56] 서적 Extreme Programming Explained: Embrace Change Addison-Wesley
_[57] 웹사이트 Agile Delivery at British Telecom http://www.methodsan[...] 2011-02-21
_[58] 학술논문 Agility XL http://www.sstc-onli[...]
_[59] 웹사이트 Bridging the Distance http://www.drdobbs.c[...] Sdmagazine.com 2011-02-01
_[60] 웹사이트 Using an Agile Software Process with Offshore Development http://www.martinfow[...] Martinfowler.com 2010-06-06
_[61] 잡지 Supersize Me http://www.drdobbs.c[...] 2006-02-15
_[62] 학술논문 Agile Processes Workshop II Managing Multiple Concurrent Agile Projects
_[63] 서적 Lean Enterprise Software and Systems 2010
_[64] 서적 Software Process Improvement and Capability Determination https://arrow.dit.ie[...] 2014-11-04
_[65] 서적 Product-Focused Software Process Improvement 2017-11-29
_[66] 웹사이트 SafeScrum - SINTEF http://www.sintef.no[...] Sintef.no 2019-03-26
_[67] 웹사이트 Scrum, documentation and the IEC 61508-3:2010 software standard http://www.sintef.no[...]
_[68] 학술논문 Scaling agile methods to regulated environments: An industry case study 2013-05
_[69] 서적 Extreme Programming Explained https://archive.org/[...] Addison-Wesley
_[70] 학술논문 Agility measurement index: a metric for the crossroads of software development methodologies
_[71] 웹사이트 Assessing Agility http://www.smr.co.uk[...] 2010-06-06
_[72] 웹사이트 Nokia test, A scrum-specific test http://agileconsorti[...] Agileconsortium.blogspot.com 2010-06-06
_[73] 웹사이트 Karlskrona test, A generic agile adoption test http://mayberg.se/le[...] Mayberg.se 2014-04-05
_[74] 웹사이트 How Agile Are You? (Take This 42 Point Test) http://www.allabouta[...] allaboutagile.com/ 2014-04-03
_[75] 웹사이트 Agile Methodologies Survey Results http://www.shinetech[...] Shine Technologies 2010-06-03
_[76] 웹사이트 2013 State of Agile report: Why Agile? http://stateofagile.[...] stateofagile.com 2014-08-13
_[77] 웹사이트 Status Quo Agile http://www.status-qu[...] 2015-07-01
_[78] 웹사이트 Survey Says: Agile Works in Practice http://www.drdobbs.c[...] 2010-06-03
_[79] 웹사이트 Answering the "Where is the Proof That Agile Methods Work" Question http://www.agilemode[...] Agilemodeling.com 2010-04-02
_[80] 논문 (정보 부족) 2008
_[81] 서적 Extreme Programming Explained https://archive.org/[...] Addison-Wesley 2000
_[82] 웹사이트 Sprint (software development) definition http://searchsoftwar[...] 2015-10-02
_[83] 웹사이트 Sprint issues – when sprints turn into crawls http://www.axisagile[...] 2014-06-08
_[84] 웹사이트 Project Roles and Responsibility Distribution http://agile-only.co[...] 2014-06-15
_[85] 웹사이트 What Does a Project Sponsor Really Do? http://blogs.pmi.org[...] 2014-06-08
_[86] 웹사이트 9th State of Agile Report http://www.versionon[...] VersionOne 2014-06-08
_[87] 서적 The Elements of Scrum Dymaxicon 2011-02-15
_[88] 웹사이트 When You Have No Product Owner at All http://www.jrothman.[...] 2014-06-08
_[89] 웹사이트 Working on Multiple Agile Teams http://techwhirl.com[...] 2014-06-14
_[90] 웹사이트 Daily Scrum Meeting http://www.mountaing[...] 2014-06-14
_[91] 웹사이트 Effective Sprint Planning http://www.agileexec[...] 2010-05-13
_[92] 웹사이트 Mission Possible: ScrumMaster and Technical Contributor http://www.agileconn[...] 2014-06-14
_[93] 웹사이트 How to Implement Agile Scrum https://aristeksyste[...] 2022-01-04
_[94] 웹사이트 Thoughts on Test Automation in Agile http://www.infoq.com[...] 2014-06-14
_[95] 웹사이트 Technical Debt + Red October http://zviband.com/p[...] 2014-06-08
_[96] 웹사이트 The Art of Agile Development: Refactoring http://www.jamesshor[...] 2014-06-14
_[97] 웹사이트 Step 4: Sprint Planning (Tasks) http://www.allabouta[...] 2014-06-14
_[98] 웹사이트 Why Limiting Your Work-in-Progress Matters http://leankit.com/b[...] 2014-06-14
_[99] 웹사이트 Sprint Planning Meeting http://www.mountaing[...] 2014-06-14
_[100] 웹사이트 Time, Resources, Scope... and Quality. http://www.adeptechl[...] 2014-06-15
_[101] 간행물 Current study on limitations of Agile 2016-01
_[102] 웹사이트 The Procurement Call for Agile, What does it mean? https://www.european[...] 2019-11-01
_[103] 서적 Managing Agile: Strategy, Implementation, Organisation and People Springer 2015
_[104] 웹사이트 Which Life Cycle Is Best for Your Project? https://pmhut.com/wh[...] 2008-10-22
_[105] 웹사이트 Agile Project Management http://www.versionon[...] 2015-06-01
_[106] 웹사이트 What is Agile Management? http://www.project-l[...] Project Laneways 2015-06-01
_[107] 서적 Personal Kanban: mapping work, navigating life Modus Cooperandi Press 2011
_[108] 웹아카이브 ADS Chapter 201 Program Cycle Operational Policy https://www.usaid.go[...] USAID 2017-04-19
_[109] 간행물 A Guide to the Project Management Body of Knowledge (PMBOK Guide) Project Management Institute
_[110] 서적 Agile Innovation ESSEC-ISIS 2013
_[111] 서적 Flexible Product Development Jossey-Bass
_[112] 서적 Getting on the Billboard Charts: Music Production as Agile Software Development Springer Science+Business Media
_[113] 서적 Managing Agile: Strategy, Implementation, Organisation and People Springer Verlag
_[114] 논문 Learning Engineering Toolkit Routledge 2022
_[115] 웹사이트 Agile programming – for your family http://www.ted.com/t[...]
_[116] 웹사이트 Top Ten Organizational Impediments to Large-Scale Agile Adoption http://www.informit.[...] InformIT 2009-08-13
_[117] 웹사이트 Introduction to Hybrid project management https://www.binfire.[...] 2016-07-20
_[118] 학술지 Overview and Guidance on Agile Development in Large Organizations
_[119] 웹사이트 Agile is a Fad http://www.batimes.c[...] 2011-07-04
_[120] 웹사이트 Agile's Teenage Crisis? http://www.infoq.com[...] InfoQ 2011-06-20
_[121] 뉴스 Against Adminspeak https://www.chronicl[...] Chronicle of Higher Education 2020-06-24
_[122] 서적 Succeeding With Agile Pearson
_[123] 문서 アジャイルソフトウェア開発宣言
_[124] 문서 アジャイルソフトウェア開発宣言の署名者
_[125] 문서 スクラムガイド (2020) https://scrumguides.[...]
_[126] 문서 スクラムガイド (2020) https://scrumguides.[...]
_[127] 문서 スクラムガイド (2020) https://scrumguides.[...]
_[128] 문서 アジャイルソフトウェア開発宣言
_[129] 문서 アジャイル宣言の背後にある原則
_[130] 문서 アジャイル宣言の背後にある原則
_[131] 문서 アジャイルソフトウェア開発宣言
_[132] 문서 アジャイル宣言の背後にある原則
_[133] 문서 アジャイルソフトウェア開発宣言
_[134] 문서 アジャイル宣言の背後にある原則
_[135] 문서 Don’t just Do Agile, Be Agile
_[136] 문서 アジャイルソフトウェア開発宣言
_[137] 문서 アジャイル宣言の背後にある原則
_[138] 문서 アジャイルソフトウェア開発宣言
_[139] 문서 アジャイル宣言の背後にある原則
_[140] 문서 ウォーターフォールプロセス https://bliki-ja.git[...]
_[141] 웹사이트 ウォーターフォールプロセス https://bliki-ja.git[...] 2019
_[142] 웹사이트 ウォーターフォールプロセス https://bliki-ja.git[...] 2019
_[143] 문서 逐次型の実行では学習した内容を適応すべき "計画" がすでに使用済みのため、理論上は存在しない。実務上、適応型計画をしているのにイテレーション#1が無限に終了しない場合はここに分類されうる。
_[144] 논문 2004
_[145] 웹사이트 Dr. Dobb's Good stuff for serious developers: Programming Tools, Code, C++, Java, HTML5, Cloud, Mobile, Testing http://www.sdmagazin[...] 20XX-XX-XX
_[146] 논문 2003
_[147] 논문 1999
_[148] 웹사이트 Cleverworks® | Digitize and automate Administrative- Sales and Marketing Processes https://www.cleverwo[...]
_[149] 웹사이트 Agile Modeling (AM) Home Page: Effective Practices for Modeling and Documentation http://www.agilemode[...]
_[150] 웹사이트 The Agile Unified Process (AUP) Home Page http://www.ambysoft.[...]
_[151] 웹사이트 DSDM Consortium - Enabling Business Agility https://web.archive.[...]
_[152] 웹사이트 XP_jp_TOP http://www.objectclu[...]
_[153] 웹사이트 Feature Driven Development | The portal for all things FDD. http://www.featuredr[...]
_[154] 웹사이트 Poppendieck.LLC http://www.poppendie[...]
_[155] 웹사이트 Control Chaos - Message from Ken http://www.controlch[...]
_[156] 웹사이트 Coming Soon – Alistair Cockburn http://alistair.cock[...]
_[157] 웹사이트 Agile/Lean Documentation: Strategies for Agile Software Development http://www.agilemode[...]
_[158] 웹사이트 Agile Data Home Page http://www.agiledata[...]
_[159] 웹사이트 The Process of Database Refactoring: Strategies for Improving Database Quality http://www.agiledata[...]